Handle 202 Accepted response in HTTP client#323
Open
atesgoral wants to merge 1 commit intomodelcontextprotocol:mainfrom
Open
Handle 202 Accepted response in HTTP client#323atesgoral wants to merge 1 commit intomodelcontextprotocol:mainfrom
atesgoral wants to merge 1 commit intomodelcontextprotocol:mainfrom
Conversation
atesgoral
force-pushed
the
ag/client-202-accepted
branch
2 times, most recently
from
bea4746 to
f7ecdf3
Compare
The Streamable HTTP spec allows a server to respond 202 Accepted when
it has received the request but will deliver the response later via an
SSE stream. The client previously errored on 202 because the response
has no parseable Content-Type. Return `{ "accepted" => true }` so the
caller can decide how to proceed.
Actually picking up the deferred response requires listening on an SSE
stream (GET-for-SSE), which is not yet implemented. This PR only
prevents the hard error on a valid server response.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
atesgoral
force-pushed
the
ag/client-202-accepted
branch
from
f7ecdf3 to
58cb5f9
Compare
koic
reviewed
Apr 19, 2026
| elsif response.status == 202 | ||
| # Server accepted the request and will deliver the response via an SSE stream. | ||
| # https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#sending-messages-to-the-server | ||
| { "accepted" => true } |
Member
There was a problem hiding this comment.
I think the spec defines 202 as the ACK for a notification/response, rather than "request accepted, SSE coming later". The TypeScript and Python SDKs also check status == 202 before Content-Type and return void rather than a Hash sentinel. In the current diff, the 202 branch comes last, so a 202 with any Content-Type header would skip it; the existing test happens to pass only because WebMock leaves Content-Type unset. Also, { "accepted" => true } overlaps with the Hash shape of real JSON-RPC responses. What do you think about something closer to this?
def parse_response_body(response, method, params)
+ # 202 Accepted is the ACK for a notification/response; no body is expected.
+ # https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#sending-messages-to-the-server
+ return if response.status == 202
+
content_type = response.headers["Content-Type"]
if content_type&.include?("text/event-stream")
parse_sse_response(response.body, method, params)
elsif content_type&.include?("application/json")
response.body
- elsif response.status == 202
- # Server accepted the request and will deliver the response via an SSE stream.
- # https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#sending-messages-to-the-server
- { "accepted" => true }
else
raise RequestHandlerError.new(...)
end
endThe tests will need a matching update as well.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Second slice of #321 (Streamable HTTP client support).
The Streamable HTTP spec allows a server to respond
202 Acceptedwhen it has received the request but will deliver the response later via an SSE stream. The client currently errors on 202 because the response has no parseableContent-Type. Return{ "accepted" => true }so callers can proceed rather than hard-fail on a valid server response.Actually picking up the deferred response requires listening on an SSE stream (GET-for-SSE), which is a TODO in the main PR and out of scope here. This change is just the graceful-no-hard-error part.
Changes
lib/mcp/client/http.rb: addelsif response.status == 202branch toparse_response_bodyreturning{ "accepted" => true }test/mcp/client/http_test.rb: test for 202 response with empty bodyTest plan
rake testpasses (738 runs, 1848 assertions)rake rubocopno new offenses on changed filesStack
connect, session-ID tracking,close/DELETE🤖 Generated with Claude Code